1. Field of the Invention
The present invention generally relates to a method and a system for performing risk management analysis. More particularly, the present invention relates to a system with a scalable architecture for performing risk management analysis and a method of using On-Line Analytical Processing (OLAP) engines to perform multi-dimensional analysis with context-dependent, heterogeneous aggregation functions.
2. Related Art
Large financial institutions typically have a large portfolio of investment positions at any given point in time. Value-at-Risk (VaR) has become the standard manner by which risk associated with the portfolio is measured within these large financial institutions. VaR is used as a quantitative measure of risk for assessment and comparison purposes. VaR was first developed as a measure of market risk to describe the potential loss incurred by unfavorable market conditions.
As used in the present discussion, the term “risk” is defined as the uncertainty of profile or a possibility of losses in a portfolio of financial securities. Risk of a portfolio thus encompasses all possible values of losses (or results of underperformance compared to a benchmark) over a fixed period of time. Risk therefore is mathematically described as a random variable. VaR is a pre-defined quantile, usually 99%, of the probability distribution of this random variable.
The market risk associated with a portfolio can be separated into “continuous market risk,” stemming from continuous fluctuations in market prices of instruments in the portfolio, and “event and default risk,” which are due to possible abrupt jumps in the instruments' prices caused by events specific to individual issuers (e.g., events affecting actual or perceived creditworthiness or future profitability of the issuers). For debt instruments, possible credit events typically include changes of externally assigned credit ratings or default (insolvency) of the instrument's issuer.
Financial institutions commonly use internal models for portfolio risk analysis. A specific risk add-on for an internal model may be an “event risk” for individual equities and their derivatives. In the case of the broad market, the one-year history of the broad market is by regulatory fiat a sufficient measure of the historical risk of the broad market. Thus the event-risk add-on for equities must be some measure of historical events spanning “a full business cycle,” which are idiosyncratic to an individual equity and not captured in a one-year VaR. An equity event is defined as a jump discontinuity in price relative to the broad market, observed during an entire business cycle, which is a larger percent price change than any price changes that were observed over the previous year and thus already incorporated into the VaR estimate.
Generally, a portfolio contains linear and non-linear positions or holdings. For linear holdings (e.g., direct-ownership stock) the VaR of the market risk can be calculated analytically. For non-linear holdings (e.g., options and derivatives) a model incorporating historical daily rate changes typically is applied to the current portfolio, in order to generate a distribution for the value of the portfolio and, therefore, the risk associated with the future of the portfolio.
The output of a risk system is a database that is generated in conformance with the above described models. The database is re-generated at least on a daily basis, and typically is re-generated, at least in part, on an intra-day basis to accommodate intra-day changes in the positions held by financial institutions. The database is queried by the risk managers of a financial institution in order to generate risk reports. Usually, these reports are generated for two purposes: to comply with regulatory requirements; and to manage the risk associated with a portfolio.
Some databases of prior-art risk-management systems are structured in the form of a multi-dimensional cube of cells (nodes). The cells represent various positions contained in a portfolio. In the prior-art risk-management systems (also referred to herein as “risk engines”) in which a multi-dimensional model is used, each cell contains only a scalar measure representing one particular measure of a position of the portfolio. For more complex risk engines of the prior art, the cube of cells has no more than ten different dimensions, such as the currency of a position, the market in which the position exists, and so on.
The nature of a multi-dimensional cube is such that that reports may easily be generated that satisfy the needs of a particular user. For example, upper management may require reports that convey executive-level information, e.g., whether a portfolio satisfies federal regulations for capital requirements. Alternatively, reports from the cube may be “drilled down” or presented at a trading-desk level, such that a trader will know exactly the predicted short-term risk associated with a portfolio being traded.
FIG. 1 schematically illustrates a risk engine of the prior art. As previously described, the positions of a portfolio must be evaluated at least on a daily basis, as the market for the investments is ever changing. Element 100 represents datastreams that supply the risk engine with raw data relative to the positions of the portfolio. The raw data to be processed is directed to one of a plurality of valuation-processing systems (pipes) 102, 104, 106, 108 in order to be valued. For example, positions that are comprised of U.S. equities are directed to a valuation processing system (pipe) 102; foreign bonds are processed by a pipe 104; options and derivatives are processed by a pipe 106, and so on. The positions, once valued by the pipes 102, 104, 106, 108, are used to populate the above-described multi-dimensional cube in a database 110.
In the prior-art system of FIG. 1, there essentially is no sharing of data and no sharing of resources. Each pipe 102, 104, 106, 108 has its own set of resources (e.g., processors) and exclusively operate on a particular type of data (e.g., U.S. equities). This architecture, although adequate for financial institutions within a certain size, is unable to keep up with increasing volumes of financial data for growing financial institutions. For example, if there is a merger of two mid-sized financial institutions into one larger institution, the risk engines of either of the institutions would not be able to accommodate the risk-management processing of the other institution. This typically leads to disparate risk engines within the combined (merged) financial institution, with potentially arbitrary assignment of data to be processed by one or the other of the risk engines.
The only way that the risk engines of either financial institution would be able to handle the increased volume would be to purchase more, larger, faster, and increasingly expensive processors and networks. But even this solution has its limits, as the architecture of the above-described prior-art risk engines can only be scaled up so much. One significant problem discovered by the present inventors is that the architecture of prior-art risk engines leads to uneven workload distribution, which in turn leads to unacceptable delays in valuation and reductions in the engines' throughput. The inventors of the present invention performed a benchmarking test of the prior-art risk engines on increasingly bigger machines and networks, and found that there is a clear limit to the extent to which a prior-art risk engine would no longer scale up.
The inventors of the present invention found that the prior-art risk engines are incapable of valuing a portfolio of one million positions for the simultaneous processing of a one-day VaR, ten-day VaR, corporate stress tests, and specific issuer risk processing in a timely manner.
OLAP engines have been used to perform portfolio risk analysis according to conventional techniques. Generally, as mentioned above, financial institutions use internal risk models for such analysis, which is inherently multi-dimensional. As such, OLAP engines provide a natural choice for performing portfolio risk analysis. However, aggregation functions used in most if not all internal risk models are context-dependent and heterogeneous. This significantly limits the ability to use the generic analysis mechanism provided by OLAP engines to perform analyses for specific conditions. That is, commonly used aggregation functions do not allow OLAP engines to be utilized to the fullest extent of their capabilities, because such aggregation functions are context-dependent and heterogeneous, and because the conventional representation of the information to be aggregated cannot be adapted to a generic analysis mechanism. Therefore, OLAP engines utilized to aggregate conventionally represented information are prevented from performing a generic risk analysis that is context-dependent and heterogeneous, and can easily be adapted to generate an analysis using desired parameters.
FIG. 8 shows an example of a data hierarchy with a tree structure, in which C0 represents a node. C1, C2, and C3 are intermediate nodes extending from C0, and C11 through C32 are leaves extending from C1, C2, or C3.
Instead of a tree structure, a data hierarchy may be represented by a cube of one or more dimensions. FIG. 9 shows a data hierarchy represented as a two-dimensional (2D) cube, in which the horizontal axis represents “Region” and the vertical axis represents “Currency.” For the multi-dimensional cube of FIG. 9, if an aggregation function f( . . . ) is a addition operation, which clearly is context-independent and homogeneous, then:C1=f(C11, C13)C2=f(C21, C22)C3=f(C31, C33)C4=f(C42, C43).That is, in the 2D (Currency, Region) cube of FIG. 9, the node C0 represents the total for the Currency and Region dimensions. The intermediate node C1 represents the total for the region “NA” or North America, which has a leaf C11 corresponding to the Japanese yen (JPY) and a leaf C13 corresponding to the American dollar (USD). The intermediate node C2 represents the total for the region “EMEA” or Europe/Middle East/Africa, which has a leaf C21 corresponding to the Japanese yen and a leaf C22 corresponding to the British pound (GBP). The intermediate node C3 represents the total for the region “ASIA” or Asia, which has a leaf C31 corresponding to the Japanese yen and a leaf C33 corresponding to the American dollar. The intermediate node C4 represents the total for the region “LA” or Latin America, which has a leaf C42 corresponding to the British pound and a leaf C43 corresponding to the American dollar.
In risk management, however, most aggregation functions are context-dependent, as mentioned above. The following is an example of a context-dependent aggregation commonly performed in market and credit management.
Table 1 shows a portfolio of positions. The positions in Table 1 may be represented as a three-dimensional (3D) cube, with the dimensions “Legal Entity,” “Currency,” and “Issuer,” as schematically shown at reference numeral 100 in FIG. 10. At the vertices of the cube 100 are cells 110, each of which contain measures for the three dimensions of the cube 100. In the case of Table 1, each cell of the cube contains the measures “MTM” (market-to-market) and “Exposure.” That is, each cell corresponding to Table 1 has three dimensions (i.e., the three dimensions of the cube 100) and two measures.
TABLE 1PORTFOLIO OF POSITIONSLegal EntityCurrencyIssuerMTMExposureFSAGBPIBM10010FRBUSDGM−200−20FSAUSDGM45030FRBGBPGM30020FRBGBPGM−300−20FSAUSDIBM−500−80FSAJPYIBM45030FRBJPYGM600−50FSAUSDGE25020FSAGBPGE−300−10FRBUSDGM15010
One of ordinary skill in the art will appreciate that although the cube 100 shown in FIG. 10 has three dimensions, the term “cube” as discussed herein is not limited to a 3D cube but instead may have more or fewer dimensions than three. Similarly, although each cell 110 in FIG. 10 is described as having three dimensions, the term “cell” as discussed herein may have more or fewer than three dimensions. Also, note that the dimension Legal Entity may be represented as a data hierarchy with a tree structure, as schematically shown in FIG. 11.
In the present example, the aggregation rules are as follows:                MTMs are netted at any level; and        Exposures are netter for an Issuer and grossed between Issuers.        
For a query to calculate MTM and Exposure by Legal Entity, aggregation according to the above aggregation rules returns the results shown in Table 2.
TABLE 2RESULTS OF LEGAL-ENTITY QUERYLegal EntityMTMExposureFRB55060FSA45080The results shown in Table 2, are obtained according to the following operations.
First, the 3D cube containing the data of Table 1 is projected onto two dimensions, Legal Entity and Issuer, by algebraically summing the MTM and Exposure measures for each cell. That is, the 3D cube is projected onto a 2D cube. The results of this summing operation are given in Table 3.
TABLE 3SUMMATION RESULTSLegal EntityIssuerMTMExposureFRBGM−200−20FRBGM30020FRBGM−300−20FRBGM600−50FRBGM15010FSAGE25020FSAGE−300−10FSAGM45030FSAIBM10010FSAIBM−500−80FSAIBM45030
Next, netting by issuers is performed by consolidating the cells. That is, for each issuer, the MTM and the Exposure is algebraically added. Results of this netting operation are given in Table 4.
TABLE 4RESULTS OF NETTINGLegal EntityIssuerMTMExposureFRBGM550−60FSAGE−5010FSAGM45030FSAIBM50−40
Finally, data from the 2D cube is projected onto one dimension, Legal Entity, by netting the MTMs and “grossing” or calculating the gross values for the Exposures. That is, the MTMs are summed algebraically and the absolute values of the Exposures are summed algebraically. The results of this projection are given in Table 5, which is the same as Table 2.
TABLE 5RESULTS OF PROJECTIONLegal EntityMTMExposureFRB55060FSA45080
The above example illustrates the conventional operations used to project a 3D cube onto a 1D cube (with the single dimension of Legal Entity, in the example). At this point, if it is desirable to further aggregate the 1D cube according to the data hierarchy of FIG. 11, an operation equivalent to summing the rows of Table 5 is performed. (A straight algebraic summation operation would yield erroneous results, because the 2D-to-1D projection resulted in the loss of information.) However, because such an aggregation is non-linear, it is necessary to go back to Table 4 and perform a netting operation by issuer. The results of this netting operation are given in Table 6.
TABLE 6RESULTS OF NETTING BY ISSUERIssuerMTMExposureGM1000−30GE−5010IBM50−40
From the results in Table 6, a netting operation is performed on the MTM data, and a grossing operation is performed on the Exposure data to arrive at the final “Corp” aggregation results, which are given in Table 7.
TABLE 7RESULTS FOR CORPCorpMTM = 1000Exposure = 80
The results in Table 7 would not have been obtained by performing netting and grossing operations on the data in Table 5, which would have given the erroneous results of MTM=1000 and Exposure=140.
Similarly, for a query to calculate MTM and Exposure by Currency, aggregation according to the above aggregation rules returns the results shown in Table 8.
TABLE 8RESULTS OF CURRENCY QUERYCurrencyMTMExposureGBP−20020JPY105080USD150120
For a query to calculate the MTM and Exposure for the entire portfolio, simple netting and grossing operations on the data in Table 8 would produce the erroneous results of MTM=1000 and Exposure=220. Instead, the corrects results are given in Table 9, which is the same as Table 7, and are obtained by going back to the 2D (Currency, Issuer) cube and performing a netting operation by issuer, analogous to the operation resulting in Table 6. Then, a netting operation is performed on the MTMs, and a grossing operation is performed on the Exposures.
TABLE 9RESULTS FOR PORTFOLIOPortfolioMTM = 1000Exposure = 80
As can been seen from the above examples, risk analysis using conventional multi-dimensional cubes cannot be reliably employed in a generic manner to produce results for queries involving context-dependent and heterogeneous aggregation functions. This is because, as dimensions of a cube are projected onto cubes of fewer and fewer dimensions, information is consolidated in the various operations performed for the projections and the original information is no longer preserved.
Referring to FIG. 8, aggregation up the data hierarchy for a context-dependent, homogeneous function is given by:C1=g(C11, C12)C2=g(C21, C22)C3=g(C31, C32)C0=g(C11, C12, C21, C22, C31, C32).where g( . . . ) represents an aggregation function that is context-dependent and homogeneous. Note that g( . . . ) is the same aggregation function regardless of what node(s) it is operating on. However, for a heterogeneous aggregation function, μj, all leaf nodes Cjk are separated into homogeneous sets, andC0=μ0(μ1({C1}), μ2({C2}), μ3({C3}), . . . μk({Ck})).That is, the aggregation function μj is not the same for all nodes, and each aggregation function μj depends on the node that it is operating on as well as neighboring nodes, and also depends on where (what level or part of the data hierarchy) an aggregation is being performed. In this way, context is provided to an aggregation.
The above examples show that, with conventional models or algorithms for queries of information, a query may not contain a dimension that provides context for an aggregation, and also may not provide context for separating nodes into homogeneous sets (e.g., the Issuer dimension in the above examples).
More specifically, the above examples show that, in the conventional uses of OLAP engines, if a second query is to be performed on original information from a first query, the second query must perform new operations on the original information and cannot use operations performed in the first query of the original information. This is due to the way the original information is represented in the conventional models. In other words, the route that is taken along a path of projections for a query determines the information represented by the lower-dimension cubes resulting from the projections, and the original information is irreversibly transformed.
As mentioned above, in the case of financial institutions, advances in market and credit-risk management has led to an increase in the use of internal risk models or algorithms for portfolio risk analysis. This type of risk analysis is inherently multi-dimensional, and OLAP engines are a natural choice for providing the analysis because OLAP engines provide a generic analysis of multi-dimensional data. However, aggregation functions used in most, if not all, conventional internal risk models are context-dependent and heterogeneous. This severely limits the applicability of the generic analysis provided by OLAP engines.
Conventional ways to solve this problem, i.e., to perform the different operations discussed above for the different queries, is to provide customized reports for certain types of aggregations. In other words, for the same set of original information, reports requiring different aggregation operations to be performed are run independently of each other. Such a solution is highly inefficient in terms of time and worker-hours. Clearly, there is a need in the art of data manipulation and processing in the field or risk management, especially manipulation and processing of financial data, for a context-independent and homogeneous method of representing multi-dimensional data, so that OLAP engines may be efficiently used to perform generic analyses.